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Abstract 


Although  most  programs  and  organizations  use  risk  management  when  developing  and  operating  soft¬ 
ware -reliant  systems,  preventable  failures  continue  to  occur  at  an  alarming  rate.  In  many  instances,  the 
root  causes  of  these  preventable  failures  can  be  traced  to  weaknesses  in  the  risk  management  practices 
employed  by  those  programs  and  organizations.  To  help  improve  existing  risk  management  practices, 
Carnegie  Mellon  University  Software  Engineering  Institute  (SEI)  researchers  undertook  a  project  to 
define  what  constitutes  best  practice  for  risk  management.  The  SEI  has  conducted  research  and  devel¬ 
opment  in  the  area  of  risk  management  since  the  early  1990s.  Past  SEI  research  has  applied  risk  man¬ 
agement  methods,  tools,  and  techniques  across  the  life  cycle  (including  acquisition,  development,  and 
operations)  and  has  examined  various  types  of  risk,  including  software  development  risk,  system  acqui¬ 
sition  risk,  operational  risk,  mission  risk,  and  information  security  risk,  among  others. 

In  this  technical  report,  SEI  researchers  have  codified  this  experience  and  expertise  by  specifying  (1)  a 
Risk  Management  Framework  that  documents  accepted  best  practice  for  risk  management  and  (2)  an 
approach  for  evaluating  a  program’s  or  organization’s  risk  management  practice  in  relation  to  the 
framework. 
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1  Introduction 


Although  most  programs  and  organizations  use  risk  management  when 
developing  and  operating  software-reliant  systems,  preventable  failures 
continue  to  occur  at  an  alarming  rate.  Several  reasons  contribute  to  the  oc¬ 
currence  of  these  failures,  including 

•  significant  gaps  in  the  risk  management  practices  employed  by  programs 
and  organizations 

•  uneven  and  inconsistent  application  of  risk  management  practices  within 
and  across  organizations 

•  ineffective  integration  of  risk  management  with  program  and  organiza¬ 
tional  management 

•  increasingly  complex  management  environment 

To  help  improve  existing  risk  management  practices,  Carnegie  Mellon® 
Software  Engineering  Institute  (SEI)  researchers  undertook  a  project  to 
define  what  constitutes  best  practice  for  risk  management.  This  technical 
report  provides  the  results  of  that  research  project  by  specifying  the  follow¬ 
ing: 

•  a  Risk  Management  Framework  that  documents  accepted  best  practice 
for  risk  management 

•  an  approach  for  evaluating  a  program’s  or  organization’s  risk  manage¬ 
ment  practice  in  relation  to  the  requirements  specified  in  the  framework 

SEI  Background  in  Since  the  early  1990s,  the  SEI  has  conducted  research  and  development  in 

Risk  Management  the  area  of  risk  management  and  has  applied  risk  management  methods, 

tools,  and  techniques  across  the  life  cycle  (including  acquisition,  develop¬ 
ment,  and  operations).  In  addition,  past  SEI  research  examined  various 
types  of  risk,  including  software  development  risk  [Dorofee  1996,  Williams 
1999,  Alberts  2009],  system  acquisition  risk  [Gallagher  1999],  operational 
risk  [Gallagher  2005],  mission  risk  [Alberts  2009]  and  information  securi¬ 
ty  risk  [Alberts  2002],  among  others.  In  this  technical  report,  SEI  research¬ 
ers  have  codified  this  experience  in  the  form  of  a  Risk  Management 
Framework. 


Occurrence  of 
Preventable  Failures 


Carnegie  Mellon  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 
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Risk  Management 
Framework 


Purpose  of  this 
Document 


Intended  Audience 


The  Risk  Management  Framework  specifies  accepted  best  practice  for  the 
discipline  of  risk  management.  The  framework  is  implementation  indepen¬ 
dent — it  defines  key  risk  management  activities,  but  does  not  specify  how 
to  perform  those  activities.  In  particular,  the  framework  helps  provide  a 

•  foundation  for  a  comprehensive  risk  management  methodology 

•  basis  for  evaluating  and  improving  a  program’s  risk  management  prac¬ 
tice 

The  Risk  Management  Framework  can  be  applied  in  all  phases  of  the  sys¬ 
tem  development  life  cycle  (e.g.,  acquisition,  development,  operations).  In 
addition,  the  framework  can  be  used  to  guide  the  management  of  many 
different  types  of  risk  (e.g.,  acquisition  program  risk,  software  development 
risk,  operational  risk,  information  security  risk). 


The  purpose  of  this  technical  report  is  to  present  the  Risk  Management 
Framework,  which  defines  the  core  set  of  activities  and  outputs  required  to 
manage  risk  effectively.  However,  this  document  does  not  provide  step-by- 
step  procedures  for  conducting  the  risk  management  activities.  Other  SEI 
documents  and  courses  provide  specific  methods,  tools,  and  techniques  for 
managing  different  types  of  risk. 


The  primary  audience  for  this  technical  report  is  people  who  are  responsi¬ 
ble  for  assessing  and  managing  risk  in  development  and  operational  set¬ 
tings.  People  who  are  interested  in  the  following  topics  might  also  find  this 
document  useful: 

•  learning  about  what  constitutes  best  practice  in  risk  management 

•  evaluating  and  improving  an  existing  risk  management  practice 
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Structure  of  This 
Document 


This  technical  report  is  divided  into  the  following  parts: 

•  Section  1:  Introduction — provides  a  brief  overview  of  the  motivation 
for  developing  the  Risk  Management  Framework  and  defines  the  au¬ 
dience  for  this  document 

•  Section  2:  Risk  Management  Concepts — presents  background  infor¬ 
mation  about  risk  management 

•  Section  3:  Framework  Overview — describes  how  the  Risk  Manage¬ 
ment  Framework  is  structured 

•  Section  4:  Prepare  for  Risk  Management  (Phase  1) — presents  activi¬ 
ties  that  are  required  to  prepare  for  risk  management 

•  Section  5:  Perform  Risk  Management  Activities  (Phase  2) — 

describes  activities  that  are  required  to  manage  risk  effectively 

•  Section  6:  Sustain  and  Improve  Risk  Management  (Phase  3) — 

presents  activities  that  are  required  to  sustain  and  improve  a  risk  man¬ 
agement  practice  over  time 

•  Section  7:  Framework  Requirements — defines  the  criteria  that  are 
used  to  establish  conformance  with  the  Risk  Management  Framework 

•  Appendix:  Evaluating  a  Risk  Management  Practice — presents  a  set 
of  worksheets  that  can  be  used  to  evaluate  a  program’s  or  organization’s 
risk  management  practice  and  establish  consistency  with  the  Risk  Man¬ 
agement  Framework 
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2  Risk  Management  Concepts 


Multiple  Contexts  of 
Risk  Management 

The  term  risk  is  used  universally,  but  different  audiences  often  attach  dif¬ 
ferent  meanings  to  it  [Kloman  1990].  In  fact,  the  details  about  risk  and  how 
it  supports  decision  making  depend  upon  the  context  in  which  it  is  applied 
[Charette  1990].  For  example,  safety  professionals  view  risk  management 
in  terms  of  reducing  the  number  of  accidents  and  injuries.  A  hospital  ad¬ 
ministrator  views  risk  as  part  of  the  organization’s  quality  assurance  pro¬ 
gram,  while  the  insurance  industry  relies  on  risk  management  techniques 
when  setting  insurance  rates.  Each  industry  thus  uses  a  definition  that  is 
uniquely  tailored  to  its  context.  No  universally  accepted  definition  of  risk 
exists. 

Three  Conditions 

of  Risk 

Whereas  specific  definitions  of  risk  might  vary,  a  few  characteristics  are 
common  to  all  definitions.  For  risk  to  exist  in  any  circumstance,  the  follow¬ 
ing  three  conditions  must  be  satisfied  [Charette  1990]: 

1 .  The  potential  for  loss  must  exist. 

2.  Uncertainty  with  respect  to  the  eventual  outcome  must  be  present.1 

3.  Some  choice  or  decision  is  required  to  deal  with  the  uncertainty  and 
potential  for  loss. 

Basic  Definition  of 

Risk 

These  three  characteristics  can  be  used  to  forge  a  very  basic  definition  of 
the  word  risk.  Most  definitions  focus  on  the  first  two  conditions — loss  and 
uncertainty — because  they  are  the  two  measurable  aspects  of  risk.  Thus,  the 
essence  of  risk,  no  matter  what  the  domain,  can  be  succinctly  captured  by 
the  following  definition:  Risk  is  the  possibility  of  suffering  loss  [Dorofee 
1996]. 

Some  researchers  separate  the  concepts  of  certainty  (the  absence  of  doubt),  risk  (where  the  probabilities  of  alternative 
outcomes  are  known),  and  uncertainty  (where  the  probabilities  of  possible  outcomes  are  unknown).  However,  because 
uncertainty  is  a  fundamental  attribute  of  risk,  we  do  not  differentiate  between  decision  making  under  risk  and  decision 
making  under  uncertainty  in  this  technical  report. 
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Components  of  Risk 


Risk  Measures 


Risk  Management 


As  illustrated  in  Figure  1 ,  a  risk  can  be  thought  of  as  a  cause-and-effect 
pair,  where  the  threat  is  the  cause  and  the  resulting  consequence  is  the  ef¬ 
fect.  In  this  context,  a  threat  is  defined  as  a  circumstance  with  the  potential 
to  produce  loss,  while  a  consequence  is  defined  as  the  loss  that  will  occur 
when  a  threat  is  realized  [Alberts  2009]. 


Cause  Effect 


I  I 

t  t 


Probability  Impact 

Figure  1:  Components  of  Risk 


Three  measures  are  associated  with  a  risk:  (1)  probability,  (2)  impact,  and 
(3)  risk  exposure.  The  relationships  between  probability  and  impact  and  the 
components  of  risk  are  shown  in  Figure  1 .  In  this  context,  probability  is 
defined  as  a  measure  of  the  likelihood  that  a  threat  will  occur,  while  impact 
is  defined  as  a  measure  of  the  loss  that  will  occur  if  the  threat  is  reahzed. 
Risk  exposure  provides  a  measure  of  the  magnitude  of  a  risk  based  on  cur¬ 
rent  values  of  probability  and  impact. 


Risk  management  is  a  systematic  approach  for  minimizing  exposure  to  po¬ 
tential  losses.  It  provides  a  disciplined  environment  for 

•  continuously  assessing  what  could  go  wrong  (i.e.,  assessing  risks) 

•  determining  which  risks  to  address  (i.e.,  setting  mitigation  priorities) 

•  implementing  actions  to  address  high-priority  risks  and  bring  those  risks 
within  tolerance 
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Risk  Management 
Activities 


Figure  2  illustrates  the  three  core  risk  management  activities: 


•  assess  risk — transform  the  concerns  people  have  into  distinct,  tangible 
risks  that  are  explicitly  documented  and  analyzed 

•  plan  for  risk  mitigation — determine  an  approach  for  addressing  or  mi- 
tigating  each  risk;  produce  a  plan  for  implementing  the  approach' 

•  mitigate  risk — deal  with  each  risk  by  implementing  its  defined  mitiga¬ 
tion  plan  and  tracking  the  plan  to  completion 

These  three  activities  form  the  foundation  of  the  Risk  Management  Frame¬ 
work. 


Figure  2:  Risk  Management  Activities 


No  universal  definition  for  the  term  mitigation  exits.  In  fact,  various  risk  management  standards  and  guidelines  use  this 
term  quite  differently.  In  this  report,  we  define  mitigation  broadly  as  any  action  taken  to  address  a  risk. 
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Issue/Problem 

One  of  the  fundamental  conditions  of  risk  is  uncertainty  regarding  its  oc¬ 
currence.  A  risk,  by  definition,  might  or  might  not  occur.  In  contrast,  an 
issue  (also  referred  to  as  a  problem  in  many  contexts)  is  a  loss  or  adverse 
consequence  that  has  occurred  or  is  certain  to  occur.  With  an  issue,  no  un¬ 
certainty  exists — the  loss  or  adverse  consequence  has  taken  place  or  is  cer¬ 
tain  to  take  place.4  Issues  can  also  lead  to  (or  contribute  to)  other  risks  by 

•  creating  a  circumstance  that  produces  a  new  threat 

•  making  an  existing  threat  more  likely  to  occur 

•  aggravating  the  consequences  of  existing  risks 

Opportunity 

Risk  is  focused  on  the  potential  for  loss;  it  does  not  address  the  potential  for 
gain.  The  concept  of  opportunity  is  used  to  address  the  potential  for  gain. 

An  opportunity  is  the  likelihood  of  realizing  a  gain  from  an  allocation  or 
reallocation  of  resources.  Opportunity  defines  a  set  of  circumstances  that 
provides  the  potential  for  a  desired  gain  and  requires  an  investment  or  ac¬ 
tion  to  realize  that  gain  (i.e.,  to  take  advantage  of  the  opportunity).  Pursuit 
of  an  opportunity  can  produce  new  risks  or  issues,  and  it  can  also  change 
existing  risks  or  issues. 

Focus  of  the  Risk 

Management 

Framework 

The  Risk  Management  Framework  (hereafter  also  referred  to  as  “the 
framework”)  defines  activities  that  are  required  to  manage  risk  effectively. 
Activities  for  managing  issues  and  opportunities  are  not  explicitly  specified 
in  the  Risk  Management  Framework.  While  risk  management  can  be  inte¬ 
grated  with  issue  and  opportunity  management  [Alberts  2009],  the  details 
for  achieving  an  integrated  approach  for  managing  risks,  issues,  and  oppor¬ 
tunities  is  beyond  the  scope  of  this  report. 

People  do  not  always  find  it  easy  to  distinguish  between  an  issue  and  the  future  risk  posed  by  that  issue  (if  left  uncor¬ 
rected).  This  confusion  can  result  in  issues  being  documented  in  a  risk  database  and  being  treated  like  risks  (and  vice 
versa).  Management  must  take  great  care  to  ensure  that  their  approaches  for  managing  issues  and  risks  are  integrated 
appropriately  and  understood  by  both  management  and  staff. 

Many  of  the  same  tools  and  techniques  can  be  applied  to  both  issue  and  risk  management. 
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3  Framework  Overview 


Introduction 


Risk  Management 
Framework:  Three 
Phases 


This  section  presents  an  overview  of  the  Risk  Management  Framework.  Figure 
3  shows  the  three  phases  of  the  framework.  The  main  goal  of  the  framework  is 
to  specify  the  core  sequence  of  activities  that  must  be  executed  when  perform¬ 
ing  risk  management  (Phase  2).  Flowever,  because  risk  management  must  be 
conducted  within  a  broader  context  or  environment,  the  framework  also  speci¬ 
fies  activities  to  prepare  for  risk  management  (Phase  1)  as  well  as  to  sustain 
and  improve  the  risk  management  practice  over  time  (Phase  3). 


\  Phase  1 

,  Prepare  for  Risk 
Management 


Phase  2 
Perform  Risk 
Management  Activities 


Phase  3 

Sustain  and  Improve 
Risk  Management 


Figure  3:  Framework  Structure 


Phase  1  (“Prepare  for  Risk  Management”)  is  used  to  get  ready  for  the  other  two 
phases.  Phase  1  activities  should  be  complete  before  activities  in  the  other 
phases  are  executed.  Phase  2  (“Perform  Risk  Management  Activities”)  defines 
a  set  of  activities  for  managing  risk.  Phase  2  activities  are  continually  per¬ 
formed  to  ensure  that  the  overall  risk  to  key  objectives  is  effectively  managed 
over  time.  The  activities  of  Phase  3  (“Sustain  and  Improve  Risk  Management”) 
are  normally  performed  on  a  periodic  basis  to  ensure  that  the  risk  management 
practice  remains  effective  over  time.  Phase  3  activities  are  used  to  identify  im¬ 
provements  to  a  risk  management  practice.  While  Phase  1  is  generally  com¬ 
pleted  prior  to  beginning  the  other  two,  Phases  2  and  3  are  typically  executed 
concurrently. 
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Specifying  The  following  common  elements  are  used  to  specify  each  phase  of  the 

Framework  Phases  framework: 

•  description  of  the  phase 

•  key  questions  answered  by  the  phase 

•  dataflow  for  the  phase  that  highlights  the  phase’s  inputs,  constraints, 
resources,  and  outputs 

•  description  of  each  input  required  by  the  activities  performed  in  the 
phase 

•  description  of  each  constraint  affecting  activities  performed  in  the  phase 

•  description  of  each  resource  required  by  activities  performed  in  the 
phase 

•  description  of  each  output  produced  by  the  activities  performed  in  the 
phase 

•  description  of  each  activity  that  must  be  performed  in  the  phase 


Specifying  Phase  2 
Activities 

•  Activity  2.1:  Assess  Risk 

•  Activity  2.2:  Plan  for  Risk  Mitigation 

•  Activity  2.3:  Mitigate  Risk 

The  following  common  elements  are  used  to  specify  each  Phase  2  activity: 

•  description  of  the  activity 

•  key  questions  answered  by  the  activity 

•  dataflow  of  inputs  and  outputs  for  the  activity 

•  descriptions  of  each  input  to  the  activity 

•  descriptions  of  each  output  produced  by  the  activity 

•  circumstances  that  trigger  execution  of  the  activity 

•  description  of  each  sub-activity  that  must  be  performed  when  conducting 
the  activity 


Phase  2  is  described  in  more  detail  than  the  other  phases  because  it  speci¬ 
fies  the  distinct  sequence  of  activities  that  uniquely  defines  a  risk  manage¬ 
ment  practice.  Phase  2  of  the  framework  comprises  the  following  three  ac¬ 
tivities: 
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Dataflow  Diagrams 


Dataflow  diagrams  are  used  to  document  phases  and  activities  in  the  Risk 
Management  Framework.  Figure  4  shows  the  structures  of  the  dataflow 
diagrams  for  a  phase  and  an  activity. 


Constraints 


Inputs 


Outputs 


Inputs 


> 


/  \ 

Framework  Activity 

V _ ) 


> 


Outputs 


Resources 


Note:  Activity  diagrams  are 
provided  for  Phase  2  only. 


Figure  4:  Structure  of  Dataflow  Diagrams 

Note  that  dataflow  diagrams  include  the  following  four  elements: 

•  inputs — items  that  are  used  by  a  phase  or  activity  to  produce  an  output  or 
result 

•  outputs — the  results  that  are  produced  by  a  phase  or  activity 

•  constraints — items  that  restrict  the  execution  of  a  phase  and  its  activities 

•  resources — items  that  can  be  used  during  the  execution  of  a  phase  and  its 
activities 

In  the  Risk  Management  Framework dataflow  diagrams  for  activities  are 
documented  only  for  Phase  2.  Because  Phase  2  defines  the  core  risk  man¬ 
agement  activities,  additional  details  are  provided  for  that  phase  of  the 
framework.  Dataflow  diagrams  are  not  provided  for  the  activities  of  Phases 
1  and  3. 

Notice  that  the  dataflow  structure  for  a  Phase  2  activity  does  not  include 
constraints  and  resources.  (Refer  to  Figure  4.)  Phase  2  constraints  and  re¬ 
sources  influence  all  activities  that  are  performed  during  that  phase.  For 
simplicity,  Phase  2  constraints  and  resources  are  documented  in  the  Phase  2 
diagram  only;  they  are  not  replicated  in  each  activity  diagram  for  Phase  2. 
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Dataflow  Identifiers 


Each  input,  output,  constraint,  and  resource  included  in  a  dataflow  is 
represented  by  an  identifier,  which  includes  a  prefix  and  a  number.  The 
prefix  is  based  on  the  type  of  data  and  the  number  represents  a  specific  data 
element  of  that  type.  For  example: 

•  C 1  is  the  first  risk  management  constraint  (affects  all  phases). 

•  R3  is  the  third  risk  management  resource  (affects  Phases  1  and  3). 

•  PI1  is  the  first  input  to  Phase  1  (preparation). 

•  04  is  the  fourth  output  of  Phase  2  (conduct  risk  management). 

•  S02  is  the  second  output  of  Phase  3  (sustainment  and  improvement). 

The  prefixes  used  in  the  dataflow  diagrams  are  listed  in  Table  1. 


Table  1:  Prefixes  Used  in  the  Dataflow  Diagrams 


Assessment  Phase 

Prefixes 

Phase  1 

PI  is  an  input  to  preparation  activities. 

PO  is  an  output  that  is  produced  when  preparation  activities  are 
performed. 

C  is  a  constraint. 

R  is  a  resource. 

Phase  2 

/  is  an  input  to  the  core  risk  management  activities  of  Phase  2. 

0  is  an  output  produced  when  the  core  risk  management 
activities  of  Phase  2  are  performed. 

C  is  a  constraint. 

PO  is  an  output  of  Phase  1  that  either  acts  as  a  constraint  or  is 
used  as  a  resource  during  Phase  2. 

Phase  3 

SI  is  an  input  to  sustainment  and  improvement  activities. 

SO  is  an  output  that  is  produced  when  sustainment  and 
improvement  activities  are  performed. 

C  is  a  constraint. 

R  is  a  resource. 
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Specifying 

Framework 

Requirements 


Framework 

Specification: 

Structure 


One  of  the  objectives  of  the  framework  is  to  provide  a  basis  for  evaluating 
and  improving  risk  management  practice  for  a  program  or  organization. 
Requirements  have  been  specified  for  each  output  in  the  framework.  These 
requirements  provide  the  basis  for  evaluating  a  risk  management  practice. 
Requirements  are  presented  for  the  following  phases  and  activities: 

•  Phase  1 :  Prepare  for  Risk  Management 

•  Phase  2:  Perform  Risk  Management  Activities, 

Activity  2.1:  Assess  Risk 

•  Phase  2:  Perform  Risk  Management  Activities, 

Activity  2.2:  Plan  for  Risk  Mitigation 

•  Phase  2:  Perform  Risk  Management  Activities, 

Activity  2.3:  Mitigate  Risk 

•  Phase  3:  Sustain  and  Improve  Risk  Management 

A  set  of  worksheets  that  can  be  used  to  evaluate  a  risk  management  prac¬ 
tice  and  establish  conformance  with  the  Risk  Management  Framework  is 
provided  in  the  appendix  of  this  report. 


The  basic  structure  of  the  Risk  Management  Framework  is  defined  as: 

•  Phase  1 :  Prepare  for  Risk  Management 

•  Phase  2:  Perform  Risk  Management  Activities 

—  Activity  2.1:  Assess  Risk 
—  Activity  2.2:  Plan  for  Risk  Mitigation 
—  Activity  2.3:  Mitigate  Risk 

•  Phase  3:  Sustain  and  Improve  Risk  Management 

•  Framework  Requirements 

This  structure  forms  the  basis  for  the  remainder  of  this  report. 
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4  Prepare  for  Risk  Management  (Phase  1) 


Description  In  this  phase,  preparation  activities  for  risk  management  are  performed. 


Key  Questions  This  phase  answers  the  following  questions: 

•  Who  is  sponsoring  risk  management? 

•  How  can  stakeholder  sponsorship  be  attained? 

•  What  is  the  plan  for  conducting  risk  management? 

•  What  resources  are  required  to  effectively  conduct  risk  management? 


Dataflow 


The  following  dataflow  describes  the  inputs  and  outputs  of  this  phase. 


Constraint 

Cl  Risk  Management  Constraints 


Input 

PI1  Stakeholder  Requirements 


Phase  1 

Prepare  for  risk 
management 

\ _ 


Outputs 

POI  Stakeholder  Sponsorship 
P02  Risk  Management  Plan 
P03  Risk  Sources 
P04  Risk  Management  Criteria 
P05  Tailored  Methods  and  Tools 
P06  Trained  Personnel 


Resources 

R1  Policies,  Standards,  Laws,  and  Regulations 
R2  Standard  Risk  Management  Practice 
R3  Experienced  Personnel 


Figure  5:  Dataflow  for  Phase  1 


Input 


The  following  is  the  input  to  this  phase. 


Input 

Description 

PI1  Stakeholder 

Requirements 

The  needs  of  the  key  stakeholders  regarding  risk  management 
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Constraint 


The  following  is  the  constraint  for  this  phase. 


Constraint 

Description 

Cl  Risk  Management 
Constraints 

Any  circumstances,  including  logistics,  standards,  laws,  regulations,  personnel, 
schedule,  and  cost  issues  that  could  affect  risk  management  activities 

Resources 


The  following  are  the  resources  required  by  this  phase. 


Resource 

Description 

R1  Policies,  Standards, 

Laws,  and  Regulations 

Any  informative  policies,  standards,  laws,  and  regulations  that  guide  the 
implementation  of  the  risk  management  practice 

R2  Standard  Risk 

Management  Practice 

The  accepted  practice  for  implementing  risk  management,  including  methods,  tools, 
procedures,  criteria,  worksheets,  automated  support  tools,  and  databases.  The 
standard  risk  management  practice  must  be  tailored  for  each  specific  application  of 
risk  management  (e.g.,  program,  organization,  technology). 

R3  Experienced  Personnel5 

A  core  group  of  people  who  are  collectively  experienced  in  all  phases  of  risk 
management.  Risk  management  roles  and  responsibilities  for  these  people  are 
defined,  and  they  have  received  training  that  is  appropriate  for  their  roles  and 
responsibilities. 

This  core  group  of  experienced  personnel  is  responsible  for  setting  up  and  sustaining  an  effective  risk  management 
practice.  Other  personnel  who  will  also  be  performing  risk  management  activities  will  be  trained  as  needed. 
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Outputs 


The  following  are  the  outputs  of  this  phase. 


Output 

Description 

POI  Stakeholder 

Sponsorship 

Active  and  visible  support  of  risk  management  by  key  stakeholders  and  decision 
makers 

P02  Risk  Management  Plan 

The  activities  a  program  intends  to  perform  when  conducting  risk  management. 

Examples  of  items  commonly  found  in  a  risk  management  plan  include 

■  the  objectives  of  the  risk  management  effort 

■  the  scope  of  the  risk  management  effort  (e.g.,  actively  participating  groups  and 
teams,  support  groups,  interfaces) 

■  resources  (e.g.,  personnel,  funding,  technology,  facilities,  and  equipment) 
needed  to  conduct  risk  management 

■  roles  and  responsibilities  for  conducting  risk  management 

■  description  of  the  risk  management  method  being  employed 

■  relationships  and  dependencies  with  other  management  practices  (e.g.,  project, 
problem/issue,  or  opportunity  management) 

•  pointers  to  the  procedures,  artifacts,  and  tools  used  in  each  risk  management 
activity 

■  the  sources  of  risk  being  assessed 

•  all  relevant  criteria  for  conducting  risk  management  activities,  including  the 
criteria  for  probability,  impact,  and  risk  exposure 

•  a  communication  framework  that  describes  formal  paths  for  sharing  risk 
information  among  key  stakeholders 

■  time  intervals  and  other  triggers  for  establishing  risk  baselines 

■  effectiveness  measures  used  to  evaluate  the  risk  management  practice 

P03  Risk  Sources 

The  causes  of  risk  that  will  be  assessed  (this  should  be  kept  current) 

P04  Risk  Management 

Criteria 

The  parameters  used  when  managing  risks,  including 

■  probability,  impact,  and  risk  exposure  criteria 

•  decision-making  criteria  (e.g.,  for  prioritizing  risks  during  mitigation  or  deciding 
when  to  escalate  risks  within  a  program  or  organization) 

•  criteria  that  establish  risk  tolerance 

•  criteria  for  communicating  with  collaborators  and  partners  as  well  as  with  senior 
management 

P05  Tailored  Methods  and 

Tools 

The  methods  and  tools  that  will  be  used  when  conducting  risk  management, 
including  procedures,  criteria,  worksheets,  automated  support  tools,  and  databases. 
Methods  and  tools  are  usually  tailored  from  a  standard  set  for  a  specific  application 
of  risk  management  (e.g.,  program,  organization,  technology). 

P06  Trained  Personnel6 

The  people  who  are  tasked  with  performing  risk  management  activities  and  are 
prepared  to  conduct  them 

The  majority  of  personnel  in  a  program  typically  receive  awareness  training  to  enable  them  to  effectively  identify  risks 
or  bring  them  to  the  attention  of  those  responsible  for  risk  management  activities.  Other  people  can  receive  more  spe¬ 
cialized  training  based  on  their  roles  in  the  risk  management  process. 
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Activities 


The  following  activities  are  performed  in  this  phase. 


Activity 

Description 

1.1  Develop  stakeholder 
sponsorship 

Meet  with  key  stakeholders  and  decision  makers  to  foster  their  active,  visible,  and 
continuous  support  of  risk  management  and  gather  their  requirements. 

1 .2  Develop  risk 
management  plan 

Create  the  plan  for  conducting  risk  management  based  on  requirements  and 
constraints  (e.g.,  schedule,  funding,  logistics,  and  contractual  restrictions). 

Note:  The  risk  management  plan  needs  to  be  consistent  with  applicable  policies, 
standards,  laws,  and  regulations. 

1 .3  Tailor  methods  and  tools 

Adapt  the  risk  management  methods  and  tools  (e.g.,  procedures,  criteria, 
worksheets,  automated  support  tools,  databases)  for  the  specific  application  of  risk 
management  (e.g.,  program,  organization,  technology). 

1 .4  Train  personnel 

Ensure  that  all  of  the  people  who  will  participate  in  risk  management  are  able  to 
effectively  perform  their  assigned  roles  and  responsibilities. 
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5  Perform  Risk  Management  Activities  (Phase  2) 


Description 


Key  Questions 


Dataflow 


In  this  phase,  risk  management  activities  are  performed  as  planned. 


This  phase  answers  the  following  questions: 

•  What  risks  could  affect  the  achievement  of  key  program  objectives? 

•  How  will  each  risk  be  addressed? 

•  What  needs  to  be  done  to  ensure  that  each  risk  is  maintained  within  an 

acceptable  tolerance  over  time? 

•  Is  each  mitigation  plan  having  its  intended  effect? 


The  following  dataflow  describes  the  inputs  and  outputs  of  this  phase. 


Constraints 

Cl  Risk  Management  Constraints 
POI  Stakeholder  Sponsorship 
P02  Risk  Management  Plan 


Input 

II  Concerns 


_ _ t _ 

f 

Phase  2 
Perform  risk 
management 
activities 
V _ 

A 

Resources 
P03  Risk  Sources 
P04  Risk  Management  Criteria 
P05  Tailored  Methods  and  Tools 
P06  Trained  Personnel 


Outputs 

01  Risk  Statement 

02  Context 

03  Probability 

04  Impact 

05  Risk  Exposure 

06  Risk  Profile 

07  Mitigation  Approach 

08  Mitigation  Plan 

09  Executed  Mitigation  Plan 

01 0  Tracking  Data 

Oil  Tracking  Decision 


Figure  6:  Dataflow  for  Phase  2 
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Input 


The  following  is  the  input  to  this  phase. 


Input 

Description 

11  Concerns 

Doubts,  worries,  and  unease  about  how  current  conditions  and  potential  events 
might  adversely  affect  the  ability  to  achieve  key  objectives 

Constraints 


The  following  are  the  constraints  for  this  phase.7 


Constraint 

Description 

Cl  Risk  Management 
Constraints 

Any  circumstances,  including  logistics,  standards,  laws,  regulations,  personnel, 
schedule,  and  cost  issues  that  could  affect  risk  management  activities 

P01  Stakeholder 

Sponsorship 

Active  and  visible  support  of  risk  management  by  key  stakeholders  and  decision 
makers. 

P02  Risk  Management  Plan 

The  activities  a  program  intends  to  perform  when  conducting  risk  management. 

Examples  of  items  commonly  found  in  a  risk  management  plan  include 

•  the  objectives  of  the  risk  management  effort 

•  the  scope  of  the  risk  management  effort  (e.g.,  actively  participating  groups  and 
teams,  support  groups,  interfaces) 

•  resources  (e.g.,  personnel,  funding,  technology,  facilities,  and  equipment) 
needed  to  conduct  risk  management 

•  roles  and  responsibilities  for  conducting  risk  management 

■  description  of  the  risk  management  method  being  employed 

■  relationships  and  dependencies  with  other  management  practices  (e.g.,  project, 
problem/issue,  or  opportunity  management) 

■  pointers  to  the  procedures,  artifacts,  and  tools  used  in  each  risk  management 
activity 

■  the  sources  of  risk  being  assessed 

•  all  relevant  criteria  for  conducting  risk  management  activities,  including  the 
criteria  for  probability,  impact,  and  risk  exposure 

•  a  communication  framework  that  describes  formal  paths  for  sharing  risk 
information  among  key  stakeholders 

•  time  intervals  and  other  triggers  for  establishing  risk  baselines 

■  effectiveness  measures  used  to  evaluate  the  risk  management  practice 

Constraints  affect  all  activities  performed  during  Phase  2.  Similarly,  resources  are  used  to  aid  the  completion  of  all 
activities  performed  during  Phase  2.  The  definitions  for  all  Phase  2  constraints  and  resources  are  provided  in  this  sec¬ 
tion  only.  They  are  not  replicated  in  the  sections  for  individual  Phase  2  activities. 
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Resources 


The  following  are  the  resources  required  by  this  phase. 


Resource 

Description 

P03  Risk  Sources 

The  causes  of  risk  that  will  be  assessed  (this  should  be  kept  current) 

P04  Risk  Management 

Criteria 

The  parameters  used  when  managing  risks,  including 

■  probability,  impact,  and  risk  exposure  criteria 

■  decision-making  criteria  (e.g.,  for  prioritizing  risks  during  mitigation  or  deciding 
when  to  escalate  risks  within  a  program  or  organization) 

■  criteria  that  establish  risk  tolerance 

■  criteria  for  communicating  with  collaborators  and  partners  as  well  as  with  senior 
management 

P05  Tailored  Methods  and 

Tools 

The  methods  and  tools  that  will  be  used  when  conducting  risk  management, 
including  procedures,  criteria,  worksheets,  automated  support  tools,  and  databases. 
Methods  and  tools  are  usually  tailored  from  a  standard  set  for  a  specific  application 
of  risk  management  (e.g.,  program,  organization,  technology). 

P06  Trained  Personnel 

The  people  who  are  tasked  with  performing  risk  management  activities  and  are 
prepared  to  conduct  them 

Outputs 

8 

The  following  are  the  outputs  of  this  phase. 

Output 

Description 

01  Risk  Statement 

A  succinct  and  unique  description  of  a  risk.  Risk  statements  typically  describe  (1)  a 
circumstance  with  the  potential  to  produce  loss  (i.e.,  threat)  and  (2)  the  loss  that  will 
occur  if  that  circumstance  is  realized  (i.e.,  consequence). 

Note-.  A  risk  statement  does  not  have  to  be  documented  using  text.  For  example,  a 
graphical  expression  or  model  can  also  be  used  to  provide  a  succinct  and  unique 
description  of  a  risk. 

02  Context 

Additional  information  essential  for  characterizing  a  risk,  including  any  relevant 
background  information  about  the  risk,  elaborations  about  the  threat  and 
consequence,  any  aggravating  or  mitigating  conditions,  and  relationships  and 
dependencies  with  other  risks 

03  Probability 

A  measure  of  the  likelihood  that  a  risk  will  occur 

04  Impact 

A  measure  of  the  severity  of  a  risk’s  consequence  if  the  risk  were  to  occur 

05  Risk  Exposure 

A  measure  of  the  magnitude  of  a  risk  based  on  current  values  of  probability  and 
impact 

Outputs  01  through  05  will  exist  for  each  risk  that  is  identified.  Output  06  provides  a  snapshot  of  all  risks  that  are 
identified.  Output  07  will  exist  for  each  risk  that  is  identified.  Finally,  outputs  08  through  01 1  will  exit  for  each  risk  that 
is  being  actively  mitigated. 
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Output 

Description 

06  Risk  Profile 

A  snapshot  or  summary  of  all  risks  relevant  to  the  specific  application  of  risk 
management  (e.g.,  program,  organization,  technology) 

07  Mitigation  Approach 

A  strategy  for  addressing  a  risk.  Examples  of  common  mitigation  approaches  include 

•  accept — If  a  risk  occurs,  its  consequences  will  be  tolerated;  no  proactive  action 
to  address  the  risk  will  be  taken.  When  a  risk  is  accepted,  the  rationale  for 
doing  so  is  documented. 

•  transfer — A  risk  is  shifted  to  another  party  (e.g.,  through  insurance  or 
outsourcing). 

•  avoid — Activities  are  restructured  to  eliminate  the  possibility  of  a  risk  occurring. 

■  control — Actions  are  implemented  in  an  attempt  to  reduce  or  contain  a  risk. 

08  Mitigation  Plan 

A  set  of  actions  for  implementing  the  selected  mitigation  approach.  Examples  of 
items  commonly  found  in  a  mitigation  plan  include 

■  objectives  of  the  plan 

■  resources  allocated  to  the  plan 

•  responsibility  for  completing  each  action  in  the  plan 

•  a  schedule  for  completing  all  actions  in  the  plan 

■  the  funding  allocated  to  performing  the  plan’s  actions 

■  measures  for  tracking  the  execution  of  the  plan  (in  relation  to  the  schedule  and 
cost)  and  the  effectiveness  of  the  plan 

■  a  contingency  plan  and  triggers  when  appropriate 

Note:  Changes  in  probability,  impact,  and  risk  exposure  (i.e.,  residual  risk)  are  often 
used  to  track  a  plan’s  effectiveness. 

09  Executed  Mitigation  Plan 

A  set  of  completed  actions  (as  outlined  in  a  mitigation  plan) 

01 0  Tracking  Data 

Specific  data  that  are  gathered  when  monitoring  the  progress  of  a  mitigation  plan 

Oil  Tracking  Decision 

Reaching  a  conclusion  or  determination  about  what  action(s)  to  take  related  to  a 
mitigation  plan.  Examples  of  common  tracking  decisions  include 

•  continue  implementing  the  mitigation  plan  as  intended 

■  modify  the  mitigation  approach  and  develop  a  new  plan  as  appropriate 

■  modify  the  mitigation  plan 

■  implement  the  contingency  plan  (if  one  exists) 

•  close  the  risk 
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Importance  of  Open  Effective  communication  among  all  stakeholders  ensures  that  information, 
Communication  plans,  actions,  concerns,  and  progress  are  known.  Risk  communication  is 

not  a  separate  activity;  it  is  embedded  in  all  other  risk  management  activi¬ 
ties.  The  importance  of  communication  is  highlighted  by  its  emphasis  in  the 
risk  management  plan,  where  a  communication  framework  for  sharing  risk 
information  among  key  stakeholders  is  documented. 

Success  cannot  be  achieved  if  risk  information  is  not  communicated  to  and 
understood  by  the  organization’s  decision  makers  and  stakeholders.  Open 
communication  requires 

•  risk  management  activities  that  are  built  upon  collaborative  approaches 

•  encouraging  exchanges  of  risk  information  among  all  levels  of  an  or¬ 
ganization 

•  using  consensus-based  processes  that  value  the  individual  voice 


Activities 


The  following  activities  are  performed  in  this  phase. 


Activity 

Description 

2.1  Assess  risk 

Transform  concerns  into  distinct,  tangible  risks  that  are  explicitly  documented  and 
measured 

2.2  Plan  for  risk  mitigation 

Determine  an  approach  for  addressing  or  mitigating  each  risk,  and  produce  a  plan 
for  implementing  the  approach 

2.3  Mitigate  risk 

Deal  with  each  risk  by  implementing  its  defined  mitigation  plan  and  tracking  it  to 
completion 
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5.1  Assess  Risk  (Activity  2.1) 


Description 


Key  Questions 


Dataflow 


This  activity  transforms  concerns  into  distinct,  tangible  risks  that  are  expli¬ 
citly  documented  and  measured.  Assessing  risk  is  an  activity  that  is  per¬ 
formed  continually. 


This  activity  answers  the  following  questions: 

•  What  is  the  statement  of  risk? 

•  What  additional  information  is  important  for  understanding  this  risk? 

—  What  are  the  root  causes  of  the  risk? 

—  What  conditions  aggravate  or  mitigate  the  risk? 

—  What  are  the  relationships  and  dependencies  with  other  risks? 

•  What  is  the  likelihood  that  the  risk  will  occur? 

•  What  is  the  severity  of  the  impact  if  the  risk  were  to  occur? 

•  What  is  the  magnitude  of  a  risk  exposure  based  on  current  values  of 
probability  and  impact? 

•  What  is  the  current  snapshot  or  profile  of  all  risks? 


The  following  dataflow  describes  the  inputs  and  outputs  of  this  activity. 


Input 

II  Concerns 


( 

Activity  2.1 
Assess  risk 

\ _ ) 


Outputs 

01  Risk  Statement 
02  Context 
03  Probability 
04  Impact 
05  Risk  Exposure 
06  Risk  Profile 


Figure  7:  Dataflow  for  Activity  2. 1 
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Input 


The  following  is  the  input  to  this  activity. 


Input 

Description 

11  Concerns 

Doubts,  worries,  and  unease  about  how  current  conditions  and  potential  events 
might  adversely  affect  the  ability  to  achieve  key  objectives 

Outputs 

The  following  are  the  outputs  of  this  activity. 

Output 

Description 

01  Risk  Statement 

A  succinct  and  unique  description  of  a  risk.  Risk  statements  typically  describe  (1)  a 
circumstance  with  the  potential  to  produce  loss  (i.e.,  threat)  and  (2)  the  loss  that  will 
occur  if  that  circumstance  is  realized  (i.e.,  consequence). 

Note:  A  risk  statement  does  not  have  to  be  documented  using  text.  For  example,  a 
graphical  expression  or  model  can  also  be  used  to  provide  a  succinct  and  unique 
description  of  a  risk. 

02  Context 

Additional  information  essential  for  characterizing  a  risk,  including  any  relevant 
background  information  about  the  risk,  elaborations  about  the  threat  and 
consequence,  any  aggravating  or  mitigating  conditions,  and  relationships  and 
dependencies  with  other  risks 

03  Probability 

A  measure  of  the  likelihood  that  a  risk  will  occur 

04  Impact 

A  measure  of  the  severity  of  a  risk’s  consequence  if  the  risk  were  to  occur 

05  Risk  Exposure 

A  measure  of  the  magnitude  of  a  risk  based  on  current  values  of  probability  and 
impact 

06  Risk  Profile 

A  snapshot  or  summary  of  all  risks  relevant  to  the  specific  application  of  risk 
management  (e.g.,  program,  organization,  technology) 

Activity  Triggers 

The  following  situations  will  trigger  this  activity: 

*  A  risk  evaluation,  appraisal,  or  audit  is  scheduled  to  be  performed. 

»  Someone  raises  a  new  concern  that  could  affect  the  ability  to  achieve  key 
objectives. 

*  Conditions  indicate  a  potential  change  in  the  current  risk  profile. 

*  A  tracking  decision  requires  a  risk  to  be  reassessed. 
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Sub-Activities 


The  following  table  describes  the  sub-activities  performed  when  conduct¬ 
ing  this  activity. 


Sub-Activity 

Description 

Outputs 

2.1.1  Identify  risk 

A  concern  is  transformed  into  a  distinct,  tangible  risk  that 
can  be  described  and  measured. 

Note:  Risks  that  are  related  can  be  grouped  to  provide  an 
aggregate  view  of  risk  to  objectives.  A  risk  statement  for 
the  group  is  documented,  and  the  statement  for  the  group 
is  carried  forward  in  the  rest  of  the  risk  management 
activities.9  Aggregating  risks  in  this  manner  helps  keep  the 
total  number  of  risks  to  a  manageable  level  without  losing 
the  broader  view. 

01  Risk  Statement 

02  Context 

2.1.2  Analyze  risk 

The  risk  is  evaluated  in  relation  to  predefined  criteria  to 
determine  its  probability,  impact,  and  risk  exposure. 

Note:  Measures  for  existing  risks  must  be  re-evaluated  on 
a  periodic  basis. 

Note:  Some  risk  management  methods  include  timeframe 
as  a  risk  measure.  Timeframe  is  the  period  when  action  is 
required  in  order  to  mitigate  a  risk.  However,  timeframe  is 
not  a  standard  risk  measure;  many  methods  do  not  use  it. 

For  this  reason,  it  is  not  included  as  a  standard  output  in 
the  framework. 

03  Probability 

04  Impact 

05  Risk  Exposure 

2.1.3  Develop  risk  profile 

A  snapshot  or  summary  of  all  risks  relevant  to  the  specific 
application  of  risk  management  (e.g.,  program, 
organization,  or  technology)  is  developed  and 
documented.  The  risk  profile  should  be  shared  with  all 
relevant  stakeholders  as  appropriate. 

06  Risk  Profile 

When  multiple  risks  are  grouped  into  an  aggregate  risk,  a  new  risk  statement  is  documented  for  the  aggregate  risk. 
The  aggregate  risk  is  handled  the  same  as  other  risks  from  this  point  forward  in  the  process. 
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5.2  Plan  for  Risk  Mitigation  (Activity  2.2) 


Description 


Key  Questions 


Dataflow 


This  activity  determines  an  approach  for  addressing  or  mitigating  a  risk, 
and  produces  a  plan  for  implementing  the  approach. 


This  activity  answers  the  following  questions  for  each  risk: 

•  How  will  the  risk  be  addressed? 

•  What  is  the  plan  for  mitigating  the  risk? 

—  What  are  the  objectives  of  the  mitigation  plan? 

—  Who  is  responsible  for  completing  each  action  in  the  plan? 

—  When  will  each  action  be  completed? 

—  How  much  funding  is  allocated  to  executing  the  plan? 

—  What  are  the  requirements  for  tracking  the  risk  mitigating  plan’s  ex¬ 
ecution  and  effectiveness? 

—  Is  a  contingency  plan  needed  for  the  risk?  If  so,  what  it  the  contin¬ 
gency  plan? 


The  following  dataflow  describes  the  inputs  and  outputs  of  this  activity. 


Inputs 

01  Risk  Statement 
02  Context 
03  Probability 
04  Impact 
05  Risk  Exposure 
06  Risk  Profile 


> 


/  \ 

Activity  2.2 
Plan  for  risk 
mitigation 

V _ ) 


Outputs 

07  Mitigation  Approach 
08  Mitigation  Plan 


Figure  8:  Dataflow  for  Activity  2.2 
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Inputs 


The  following  are  the  inputs  to  this  activity. 


Input 

Description 

01  Risk  Statement 

A  succinct  and  unique  description  of  a  risk.  Risk  statements  typically  describe  (1)  a 
circumstance  with  the  potential  to  produce  loss  (i.e.,  threat)  and  (2)  the  loss  that  will 
occur  if  that  circumstance  is  realized  (i.e.,  consequence). 

Note.  A  risk  statement  does  not  have  to  be  documented  using  text.  For  example,  a 
graphical  expression  or  model  can  also  be  used  to  provide  a  succinct  and  unique 
description  of  a  risk. 

02  Context 

Additional  information  essential  for  characterizing  a  risk,  including  any  relevant 
background  information  about  the  risk,  elaborations  about  the  threat  and 
consequence,  any  aggravating  or  mitigating  conditions,  and  relationships  and 
dependencies  with  other  risks 

03  Probability 

A  measure  of  the  likelihood  that  a  risk  will  occur 

04  Impact 

A  measure  of  the  severity  of  a  risk’s  consequence  if  the  risk  were  to  occur 

05  Risk  Exposure 

A  measure  of  the  magnitude  of  a  risk  based  on  current  values  of  probability  and 
impact 

06  Risk  Profile 

A  snapshot  or  summary  of  all  risks  relevant  to  the  specific  application  of  risk 
management  (e.g.,  program,  organization,  technology) 

Outputs 

The  following  are  the  outputs  of  this  activity. 

Output 

Description 

07  Mitigation  Approach 

A  strategy  for  addressing  a  risk.  Examples  of  common  mitigation  approaches  include 

■  accept — If  a  risk  occurs,  its  consequences  will  be  tolerated;  no  proactive  action 
to  address  the  risk  will  be  taken.  When  a  risk  is  accepted,  the  rationale  for 
doing  so  is  documented. 

•  transfer — A  risk  is  shifted  to  another  party  (e.g.,  through  insurance  or 
outsourcing). 

•  avoid — Activities  are  restructured  to  eliminate  the  possibility  of  a  risk  occurring. 

■  control — Actions  are  implemented  in  an  attempt  to  reduce  or  contain  a  risk. 
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Output 

Description 

08  Mitigation  Plan 

A  set  of  actions  for  implementing  the  selected  mitigation  approach.  Examples  of 
items  commonly  found  in  a  mitigation  plan  include 

•  objectives  of  the  plan 

•  resources  allocated  to  the  plan 

■  responsibility  for  completing  each  action  in  the  plan 

■  a  schedule  for  completing  all  actions  in  the  plan 

■  the  funding  allocated  to  performing  the  plan’s  actions 

•  measures  for  tracking  the  execution  of  the  plan  (in  relation  to  the  schedule  and 
cost)  and  the  effectiveness  of  the  plan 

•  a  contingency  plan  and  triggers  when  appropriate 

Note:  Changes  in  probability,  impact,  and  risk  exposure  (i.e.,  residual  risk)  are  often 
used  to  track  a  plan’s  effectiveness. 

Activity  T riggers  The  following  situations  will  trigger  this  activity: 

•  A  risk  has  been  assessed  (or  reassessed). 

•  A  tracking  decision 

—  changes  the  mitigation  approach 

—  calls  for  a  new  or  modified  mitigation  plan 

Sub-Activities  The  following  table  describes  the  sub-activities  performed  when  conduct¬ 

ing  this  activity. 


Sub-Activity 

Description 

Outputs 

2.2.1  Determine  mitigation 
approach 

The  strategy  for  addressing  a  risk  is  based  on  the  current 
measures  for  the  risk  (i.e.,  probability,  impact,  and  risk 
exposure).  Decision-making  criteria  (e.g.,  for  prioritizing 
risks  during  mitigation  or  deciding  when  to  escalate  risks 
within  a  program  or  organization)  may  also  be  used  to  help 
determine  the  appropriate  strategy  for  addressing  a  risk. 
Common  mitigation  approaches  include 

■  accept — If  a  risk  occurs,  its  consequences  will  be 
tolerated:  no  proactive  action  to  address  the  risk  will 
be  taken.  When  a  risk  is  accepted,  the  rationale  for 
doing  so  is  documented. 

■  transfer — A  risk  is  shifted  to  another  party  (e.g., 
through  insurance  or  outsourcing). 

■  avoid — Activities  are  restructured  to  eliminate  the 
possibility  of  a  risk  occurring. 

■  control — Actions  are  implemented  in  an  attempt  to 
reduce  or  contain  a  risk. 

Mitigation  approaches  should  be  shared  with  all  relevant 
stakeholders  as  appropriate. 

07  Mitigation 

Approach 
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Sub-Activity 

Description 

Outputs 

2.2.2  Develop  mitigation  plan 

A  mitigation  plan  is  defined  and  documented.  Mitigation 
plans  should  be  shared  with  all  relevant  stakeholders  as 
appropriate. 

Note:  More  than  one  risk  might  share  a  common  root 
cause.  Relationships  between  risks  (including  those  within 
an  aggregate  risk  or  between  the  smaller  risks  in  different 
aggregate  groups)  can  point  to  more  effective  mitigation 
actions.  Mitigation  actions  should  maximize  the  return  on 
investment  for  resources. 

08  Mitigation  Plan 
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5.3  Mitigate  Risk  (Activity  2.3) 


Description  This  activity  deals  with  the  risk  by  implementing  the  defined  mitigation 

plan  and  tracking  it  to  completion. 

Key  Questions  This  activity  answers  the  following  questions  for  each  mitigation  plan: 

•  Is  the  mitigation  plan  being  implemented  as  planned? 

•  Is  the  mitigation  plan  having  its  intended  effect? 

•  Based  on  tracking  data,  do  any  corrective  actions  need  to  be  taken? 


Dataflow  The  following  dataflow  describes  the  inputs  and  outputs  of  this  activity. 


Inputs 

01  Risk  Statement 
02  Context 
03  Probability 
04  Impact 
05  Risk  Exposure 
06  Risk  Profile 
07  Mitigation  Approach 
08  Mitigation  Plan 


Figure  9:  Dataflow  for  Activity  2. 3 


Inputs  The  following  are  the  inputs  to  this  activity. 


Activity  2.3 
Mitigate  risk 


Outputs 

09  Executed  Mitigation  Plan 
->  01 0  Tracking  Data 
Oil  Tracking  Decision 


Input 

Description 

01  Risk  Statement 

A  succinct  and  unique  description  of  a  risk.  Risk  statements  typically  describe  (1)  a 
circumstance  with  the  potential  to  produce  loss  (i.e.,  threat)  and  (2)  the  loss  that  will 
occur  if  that  circumstance  is  realized  (i.e.,  consequence). 

Note:  A  risk  statement  does  not  have  to  be  documented  using  text.  For  example,  a 
graphical  expression  or  model  can  also  be  used  to  provide  a  succinct  and  unique 
description  of  a  risk. 

02  Context 

Additional  information  essential  for  characterizing  a  risk,  including  any  relevant 
background  information  about  the  risk,  elaborations  about  the  threat  and 
consequence,  any  aggravating  or  mitigating  conditions,  and  relationships  and 
dependencies  with  other  risks 

03  Probability 

A  measure  of  the  likelihood  that  a  risk  will  occur 
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Input 

Description 

04  Impact 

A  measure  of  the  severity  of  a  risk’s  consequence  if  the  risk  were  to  occur 

05  Risk  Exposure 

A  measure  of  the  magnitude  of  a  risk  based  on  current  values  of  probability  and 
impact 

06  Risk  Profile 

A  snapshot  or  summary  of  all  risks  relevant  to  the  specific  application  of  risk 
management  (e.g.,  program,  organization,  technology) 

07  Mitigation  Approach 

A  strategy  for  addressing  a  risk.  Examples  of  common  mitigation  approaches  include 

•  accept — If  a  risk  occurs,  its  consequences  will  be  tolerated;  no  proactive  action 

to  address  the  risk  will  be  taken.  When  a  risk  is  accepted,  the  rationale  for 
doing  so  is  documented. 

■  transfer — A  risk  is  shifted  to  another  party  (e.g.,  through  insurance  or 
outsourcing). 

■  avoid — Activities  are  restructured  to  eliminate  the  possibility  of  a  risk  occurring. 

■  control — Actions  are  implemented  in  an  attempt  to  reduce  or  contain  a  risk. 

08  Mitigation  Plan 

A  set  of  actions  for  implementing  the  selected  mitigation  approach.  Examples  of 
items  commonly  found  in  a  mitigation  plan  include 

■  objectives  of  the  plan 

■  resources  allocated  to  the  plan 

■  responsibility  for  completing  each  action  in  the  plan 

•  a  schedule  for  completing  all  actions  in  the  plan 

•  the  funding  allocated  to  performing  the  plan’s  actions 

■  measures  for  tracking  the  execution  of  the  plan  (in  relation  to  the  schedule  and 
cost)  and  the  effectiveness  of  the  plan 

■  a  contingency  plan  and  triggers  when  appropriate 

Note:  Changes  in  probability,  impact,  and  risk  exposure  (i.e.,  residual  risk)  are  often 
used  to  track  a  plan’s  effectiveness. 

Outputs 

The  following  are  the  outputs  of  this  activity. 

Output 

Description 

09  Executed  Mitigation  Plan 

A  set  of  completed  actions  (as  outlined  in  a  mitigation  plan) 

01 0  Tracking  Data 

Specific  data  that  are  gathered  when  monitoring  the  progress  of  a  mitigation  plan 

Oil  Tracking  Decision 

Reaching  a  conclusion  or  determination  about  what  action(s)  to  take  related  to  a 
mitigation  plan.  Examples  of  common  tracking  decisions  include 

•  continue  implementing  the  mitigation  plan  as  intended 

•  modify  the  mitigation  approach  and  develop  a  new  plan  as  appropriate 

■  modify  the  mitigation  plan 

■  implement  the  contingency  plan  (if  one  exists) 

■  close  the  risk 
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Activity  Trigger 


The  following  situation  will  trigger  this  activity:  a  mitigation  plan  has  been 
developed  or  modified. 


Sub-Activities 


The  following  table  describes  the  sub-activities  performed  when  conduct¬ 
ing  this  activity. 


Sub-Activity 

Description 

Outputs 

2.3.1  Implement  mitigation 
plan 

The  mitigation  plan  (or  the  contingency  plan)  is  executed 
as  intended. 

09  Executed 

Mitigation  Plan 

2.3.2  Track  mitigation  plan 

The  measures  for  tracking  the  action  plan’s  execution  are 
collected  and  analyzed  as  specified  in  the  mitigation  plan. 
Tracking  data  should  be  shared  with  all  relevant 
stakeholders  as  appropriate. 

01 0  Tracking  Data 

2.3.3  Make  tracking  decision 

A  decision  about  whether  to  take  corrective  action(s) 
related  to  a  risk  or  it’s  mitigation  plan  is  made.  Tracking 
decisions  should  be  shared  with  all  relevant  stakeholders 
as  appropriate. 

01 1  Tracking 

Decisions 
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6  Sustain  and  Improve  Risk  Management  (Phase  3) 


Description 


Key  Questions 


Dataflow 


In  this  phase,  activities  are  performed  to  sustain  and  improve  risk  manage¬ 
ment  effort  over  time. 


This  phase  answers  the  following  questions: 

•  Which  risk  management  assets  (e.g.,  methods,  tools)  and  work  products 
(e.g.,  risk  profile,  mitigation  plans)  need  to  be  under  configuration  con¬ 
trol? 

•  What  lessons  were  learned  when  preparing  for  risk  management? 

•  What  lessons  were  learned  when  conducting  risk  management? 

•  How  does  the  risk  management  practice  (e.g.,  plan,  methods,  tools,  re¬ 
sources,  training)  need  to  be  updated  or  improved? 


The  following  dataflow  describes  the  inputs  and  outputs  of  this  phase. 


Constraint 

Cl  Risk  Management  Constraints 


Inputs 

PI1  Stakeholder  Requirements 

511  Risk  Management  Results 

512  Risk  Management  Effectiveness  Data 

513  Risk  Management  Practice 

V. 


Resources 

R1  Policies,  Standards,  Laws,  and  Regulations 
R2  Standard  Risk  Management  Practice 
R3  Experienced  Personnel 
R4  Sustainment/Improvement  Procedures 
R5  Sustainment/Improvement  Artifacts  and  Tools 
P02  Risk  Management  Plan 


Phase  3 

Sustain  and  improve 
risk  management 


Outputs 

501  Controlled  Risk  Management  Assets  and  Work  Products 

502  Lessons  Learned 

503  Updates  to  Risk  Management  Practice 


Figure  1 0:  Dataflow  for  Phase  3 
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Inputs 

rhe  following  are  the  inputs  to  this  phase. 

Input 

Description 

PI1  Stakeholder 

Requirements 

The  needs  of  the  key  stakeholders  regarding  risk  management 

SI1  Risk  Management 

Results 

All  outputs  and  data  produced  when  preparing  for  and  conducting  risk  management, 
including  the  risk  management  plan,  risks,  mitigation  plans,  and  risk  tracking  data 

SI2  Risk  Management 
Effectiveness  Data 

Specific  data  that  are  gathered  to  evaluate  the  effectiveness  of  the  risk  management 
practice 

SI3  Risk  Management 

Practice 

The  accepted  approach  for  performing  risk  management  activities,  including  the  risk 
management  plan,  methods,  tools,  resources,  and  training 

Constraint 

The  following  is  the  constraint  for  this  phase. 

Constraint 

Description 

Cl  Risk  Management 
Constraints 

Any  circumstances,  including  logistics,  standards,  laws,  regulations,  personnel, 
schedule,  and  cost  issues  that  could  affect  risk  management  activities 

Resources 

rhe  following  are  the  resources  required  by  this  phase. 

Resource 

Description 

R1  Policies,  Standards, 

Laws,  and  Regulations 

Any  informative  policies,  standards,  laws,  and  regulations  that  guide  the 
implementation  of  the  risk  management  practice 

R2  Standard  Risk 

Management  Practice 

The  accepted  practice  for  implementing  risk  management,  including  methods,  tools, 
procedures,  criteria,  worksheets,  automated  support  tools,  and  databases.  The 
standard  risk  management  practice  must  be  tailored  for  each  specific  application  of 
risk  management  (e.g.,  program,  organization,  technology). 

R3  Experienced  Personnel 

A  core  group  of  people  who  are  collectively  experienced  in  all  phases  of  risk 
management.  Risk  management  roles  and  responsibilities  for  these  people  are 
defined,  and  they  have  received  training  that  is  appropriate  for  their  roles  and 
responsibilities. 

R4  Sustainment/ 

Improvement  Procedures 

Documentation  that  describes  how  to  conduct  sustainment  and  improvement 
activities 

R5  Sustainment/ 

Improvement  Artifacts  and 
Tools 

Basic  items  that  can  be  used  when  conducting  sustainment  and  improvement 
activities,  including  templates,  worksheets,  standard  presentations,  automated  tools, 
and  databases 
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Resource 

Description 

P02  Risk  Management  Plan 

The  activities  a  program  intends  to  perform  when  conducting  risk  management. 

Examples  of  items  commonly  found  in  a  risk  management  plan  include 

•  the  objectives  of  the  risk  management  effort 

•  the  scope  of  the  risk  management  effort  (e.g.,  actively  participating  groups  and 
teams,  support  groups,  interfaces) 

•  resources  (e.g.,  personnel,  funding,  technology,  facilities,  and  equipment) 
needed  to  conduct  risk  management 

■  roles  and  responsibilities  for  conducting  risk  management 

■  description  of  the  risk  management  method  being  employed 

■  relationships  and  dependencies  with  other  management  practices  (e.g.,  project, 
problem/issue,  or  opportunity  management) 

■  pointers  to  the  procedures,  artifacts,  and  tools  used  in  each  risk  management 
activity 

•  the  sources  of  risk  being  assessed 

•  all  relevant  criteria  for  conducting  risk  management  activities,  including  the 
criteria  for  probability,  impact,  and  risk  exposure 

•  a  communication  framework  that  describes  formal  paths  for  sharing  risk 
information  among  key  stakeholders 

•  time  intervals  and  other  triggers  for  establishing  risk  baselines 

■  effectiveness  measures  used  to  evaluate  the  risk  management  practice 

Outputs 

The  following  are  the  outputs  of  this  phase. 

Output 

Description 

SOI  Controlled  Risk 
Management  Assets  and 

Work  Products 

Selected  risk  management  assets  (e.g.,  methods,  tools)  and  work  products  (e.g.,  risk 
profile,  mitigation  plans)  that  are  under  configuration  control 

S02  Lessons  Learned 

Knowledge  gained  by  preparing  for  and  conducting  risk  management  activities  that 
can  be  used  to  modify  and  improve  the  risk  management  practice 

S03  Updates  to  Risk 
Management  Practice 

Any  changes  to  the  risk  management  practice  (e.g.,  changes  to  the  risk 
management  plan,  methods,  tools,  resources,  training  )  to  improve  the  efficiency  and 
effectiveness  of  its  application 
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Activities 


The  following  activities  are  performed  in  this  phase. 


Activity 

Description 

3.1  Manage  risk 
management  assets  and 
work  products 

Place  designated  assets  (e.g.,  methods,  tools)  and  work  products  (e.g.,  risk  profile, 
mitigation  plans)  of  the  risk  management  practice  under  appropriate  levels  of 
control. 

3.2  Evaluate  effectiveness  of 
risk  management  practice 

Analyze  risk  management  results  and  effectiveness  measures  (as  specified  in  the 
risk  management  plan)  to  identify  and  document  lessons  learned  regarding  the 
strengths  and  weaknesses  of  the  risk  management  practice  (e.g.,  risk  management 
plan,  methods,  tools,  resources,  training). 

3.3  Implement  improvements 
to  risk  management  practice 

Make  identified  changes  to  the  risk  management  practice  (e.g.,  changes  to  the  risk 
management  plan,  methods,  tools,  resources,  training)  based  on  lessons  learned. 
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7  Framework  Requirements 


Framework  requirements  define  criteria  that  are  used  to  establish  confor¬ 
mance  with  the  Risk  Management  Framework.  A  requirement  is  specified 
for  each  output  in  the  framework.  Requirements  are  presented  for  the  fol¬ 
lowing  phases  and  activities: 

•  Phase  1 :  Prepare  for  Risk  Management 

•  Phase  2:  Perform  Risk  Management  Activities, 

Activity  2. 1 :  Assess  Risk 

•  Phase  2:  Perform  Risk  Management  Activities, 

Activity  2.2:  Plan  for  Risk  Mitigation 

•  Phase  2:  Perform  Risk  Management  Activities, 

Activity  2.3:  Mitigate  Risk 

•  Phase  3:  Sustain  and  Improve  Risk  Management 

The  appendix  of  this  document  provides  a  set  of  worksheets  for  evaluating 
a  risk  management  practice  against  the  framework  requirements. 


Phase  1  The  following  are  the  framework  requirements  for  Phase  1:  Prepare  for 

Requirements  Risk  Management. 


Framework 

Requirements 


Requirement 

Related  Output 

REQ  1  Support  of  risk  management  by  key  stakeholders  is  tangible,  active,  and 

visible. 

Examples  of  sponsorship 

Organizational  policies;  memos  from  senior  management;  resources; 
funding;  risks  discussed  at  management  meetings 

POI  Stakeholder 
Sponsorship 

REQ  2  A  risk  management  plan  is  defined,  documented,  and  approved. 

Examples  of  plan  content 

Objectives;  scope;  resources;  descriptions  of  methods  and  tools; 
sources  of  risk;  risk  management  criteria;  communication  framework; 
schedule  and  triggers  for  conducting  evaluations;  effectiveness 
measures 

P02  Risk  Management 

Plan 
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Requirement 

Related  Output 

REQ  3  Risk  sources  are  defined,  documented,  and  kept  current. 

P03  Risk  Sources 

Examples  of  documents  containing  risk  sources 

Publicly  available  lists  and  taxonomies;  domain-specific  lists  and 
taxonomies;  organizational  lists  and  taxonomies 

Examples  of  risk  categories 

Program  management,  technical,  organizational,  infrastructure,  support 
services,  and  product 

REQ  4  Risk  management  criteria  are  defined  and  documented. 

P04  Risk  Management 

Examples  of  risk  management  criteria 

Probability,  impact,  and  risk  exposure  criteria;  decision-making  criteria 
(e.g.,  for  escalation  or  prioritization);  criteria  that  establish  risk  tolerance; 
criteria  for  communicating  with  collaborators,  partners,  subcontractors, 
suppliers,  customers,  and  other  stakeholders 

Criteria 

REQ  5  Methods  and  tools  used  to  support  risk  management  activities  have 

been  appropriately  tailored  for  use. 

P05  Tailored  Methods 

and  Tools 

Examples  of  methods  and  tools 

Procedures  for  conducting  risk  management  activities;  risk 
management  criteria;  risk  sources;  worksheets;  automated  support 
tools;  report  generators;  databases 

REQ  6  People  who  perform  risk  management  activities  are  prepared  to  conduct 

them. 

P06  Trained  Personnel 

Examples  of  people  who  need  training 

Managers,  technical  leads,  and  staff  who  participate  in  risk 
management  activities;  risk  manager;  risk  database  administrator 

Examples  of  types  of  training 

Awareness  training;  method  training;  tool  training 

Phase  2,  Activity  2.1  The  following  are  the  framework  requirements  for  Phase  2:  Perform  Risk 
Requirements  Management  Activities,  Activity  2.1:  Assess  Risk. 


Requirement 

Related  Output 

REQ  7  A  risk  statement  is  documented  for  each  risk  using  a  standard  format. 

01  Risk  Statement 

Examples  of  items  that  influence  the  format  and  use  of  risk  statements 
Organizational  guidance  for  communicating,  documenting,  and  updating 
risks;  requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders 
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Requirement 

Related  Output 

REQ  8  Context  is  documented  for  each  risk. 

02  Context 

Examples  of  items  that  influence  the  format  and  use  of  context 
Organizational  guidance  for  communicating,  documenting,  and  updating 
risks;  requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders 

Examples  of  context 

Root  causes;  aggravating  conditions;  mitigating  conditions;  relationships 
and  dependencies  with  other  risks 

REQ  9  Probability  is  evaluated  and  documented  for  each  risk. 

03  Probability 

Examples  of  items  that  influence  the  use  of  probability 

Probability  criteria;  organizational  guidance  for  assessing  probability; 
requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders 

REQ  10  Impact  is  evaluated  and  documented  for  each  risk. 

04  Impact 

Examples  of  items  that  influence  the  use  of  impact 

Impact  criteria;  organizational  guidance  for  assessing  impact; 
requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders 

REQ  1 1  Risk  exposure  is  evaluated  and  documented  for  each  risk. 

05  Risk  Exposure 

Examples  of  items  that  influence  the  use  of  risk  exposure 

Risk  exposure  criteria;  organizational  guidance  for  assessing  risk 
exposure;  requirements  of  methods  and  tools;  needs  of  decision 
makers,  collaborators,  partners,  subcontractors,  suppliers,  customers, 
and  other  stakeholders 

REQ  12  A  profile  of  all  risks  is  developed,  documented,  and  kept  current. 

06  Risk  Profile 

Examples  of  items  that  influence  the  development  of  a  risk  profile 
Organizational  guidance  for  communicating,  documenting,  and  updating 
the  risk  profile;  requirements  of  methods  and  tools;  format  of  risk 
statements;  risk  profile  format;  needs  of  decision  makers,  collaborators, 
partners,  subcontractors,  suppliers,  customers,  and  other  stakeholders 
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Phase  2,  Activity  2.2  The  following  are  the  framework  requirements  for  Phase  2:  Perform  Risk 
Requirements  Management  Activities,  Activity  2.2:  Plan  for  Risk  Mitigation. 


Requirement 

Related  Output 

REQ  13  A  mitigation  approach  is  established  and  documented  for  each  risk. 

Examples  of  items  that  influence  selection  of  a  mitigation  approach 
Organizational  guidance  for  communicating,  documenting,  and  updating 
a  mitigation  approach;  requirements  of  methods  and  tools;  needs  of 
decision  makers,  collaborators,  partners,  subcontractors,  suppliers, 
customers,  and  other  stakeholders;  risk  tolerance;  decision-making 
criteria 

Examples  of  common  mitigation  approaches 

Accept  a  risk  and  take  no  action;  transfer  a  risk  to  another  party; 
restructure  activities  to  avoid  a  risk  by  eliminating  the  possibility  of  it 
occurring;  take  action  to  reduce  or  contain  a  risk 

07  Mitigation  Approach 

REQ  14  A  mitigation  plan  is  defined  and  documented  for  each  risk  that  is 

actively  being  addressed. 

Examples  of  items  that  influence  development  of  a  mitigation  plan 
Organizational  guidance  for  communicating,  documenting,  and  updating 
a  mitigation  plan;  requirements  of  methods  and  tools;  needs  of  decision 
makers,  collaborators,  partners,  subcontractors,  suppliers,  customers, 
and  other  stakeholders;  risk  tolerance 

Examples  of  a  mitigation  plan’s  content 

Objectives  for  the  plan;  resources  responsible  for  completing  each 
action;  schedule  for  completing  all  actions;  funding  allocated  to 
performing  the  plan’s  actions;  measures  for  tracking  the  execution  of 
the  plan  (in  relation  to  the  schedule  and  cost);  measures  for  tracking  the 
effectiveness  of  the  plan;  a  contingency  plan  and  triggers  when 
appropriate 

08  Mitigation  Plan 

Phase  2,  Activity  2.3  The  following  are  the  framework  requirements  for  Phase  2:  Perform  Risk 
Requirements  Management  Activities,  Activity  2.3:  Mitigate  Risk. 


Requirement 

Related  Output 

REQ  15  Mitigation  plans  are  implemented  as  intended  (unless  circumstances 

force  a  change  in  direction). 

Examples  of  items  that  influence  plan  execution 

Resources  available  for  plan  execution;  funding  allocated  to  the  plan; 
responsibility  for  implementing  the  plan;  authority  for  implementing  plan; 
verification  of  completion;  visible  support  of  management 

Examples  of  data  that  can  be  used  to  evaluate  plan  implementation 
Tracking  measures  for  effectiveness  and  efficiency  of  mitigation  plan 
execution;  tracking  measures  for  verifying  plan  completion;  triggers  for 
contingency  or  alternate  plans 

09  Executed  Mitigation 

Plan 

42  |  CMU/SEI-2010-TR-017 


Requirement 

Related  Output 

REQ  16  Data  for  tracking  mitigation  plans  are  collected,  analyzed,  documented, 

and  reported. 

Examples  of  items  that  influence  collection  of  tracking  data 

Organizational  guidance  for  selecting  tracking  measures;  organizational 
guidance  for  communicating,  documenting,  and  updating  tracking  data; 
requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders;  approach  for  collecting  measurement  data;  approach  for 
analyzing  measurement  data;  frequency  requirements  for  collecting 
tracking  data 

Examples  of  types  of  tracking  measures 

Tracking  measures  for  effectiveness  and  efficiency  of  mitigation  plan 
execution;  tracking  measures  for  verifying  plan  completion;  triggers  for 
contingency  or  alternate  plans 

01 0  Tracking  Data 

REQ  17  Tracking  decisions  for  mitigation  plans  are  documented  appropriately. 

Examples  of  items  that  influence  tracking  decisions 

Organizational  guidance  for  communicating,  documenting,  and  updating 
tracking  decisions;  requirements  for  approving  tracking  decisions; 
requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders;  decision-making  criteria 

Examples  of  common  tracking  decisions 

Modify  the  mitigation  approach  and  develop  a  new  plan;  modify  an 
existing  mitigation  plan;  implement  a  contingency  plan;  close  a  risk 

Oil  Tracking  Decisions 

Phase  3  The  following  are  the  framework  requirements  for  Phase  3:  Sustain  and 

Requirements  Improve  Risk  Management. 


Requirement 

Related  Output 

REQ  18  Selected  risk  management  assets  and  work  products  are  under 

configuration  control. 

Examples  of  assets  under  configuration  control 

Risk  management  plan;  methods  and  tools;  risk  sources,  risk  criteria 

Examples  of  work  products  under  configuration  control 

Risk  profile;  mitigation  plans;  tracking  decisions;  status  reports 

SOI  Controlled  Risk 

Management  Assets 
and  Work  Products 

REQ  1 9  Lessons  learned  are  collected  and  documented  for  the  risk 

management  practice. 

Examples  of  items  that  influence  lessons  learned 

Requirements  for  developing  lessons  learned;  needs  of  decision 
makers,  collaborators,  partners,  subcontractors,  suppliers,  customers, 
and  other  stakeholders;  types  of  effectiveness  measures  collected  for 
the  risk  management  practice;  strengths  of  the  risk  management 
practice;  weaknesses  of  the  risk  management  practice;  changes  in  best 
practices;  new  standards  or  changes  to  existing  standards  or 
regulations;  new  methods  and  tools  or  changes  to  existing  methods  and 
tools 

S03  Lessons  Learned 
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Requirement 

Related  Output 

REQ  20  The  risk  management  practice  is  updated  as  appropriate  based  on 

lessons  learned. 

Examples  of  items  that  influence  how  lessons  are  incorporated 

Change  management  process;  organizational  guidance  for  managing 
change;  needs  of  decision  makers,  collaborators,  partners, 
subcontractors,  suppliers,  customers,  and  other  stakeholders 

Examples  of  items  that  could  be  updated  or  changed 

Risk  management  plan;  funding  for  risk  management;  methods;  tools; 
resources;  training 

S03  Updates  to  Risk 
Management 

Practice 
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Appendix:  Evaluating  a  Risk  Management  Practice 


This  appendix  provides  a  set  of  worksheets  that  can  be  used  to  evaluate  a  risk  management  practice  and 
establish  conformance  with  the  Risk  Management  Framework.  Conformance  is  established  through  sa¬ 
tisfaction  of  the  framework  requirements.  Non-conformance  to  any  requirement  generally  indicates  a 
less  effective  and  potentially  inadequate  risk  management  practice. 

Directions: 

You  must  complete  the  following  two  steps  when  evaluating  each  requirement. 


1.  Evaluate  each  requirement  in  the  checklist  by  checking  the  most  appropriate  box.  The 
following  table  defines  the  range  of  responses  for  each  requirement. 


Response 

Definition 

Satisfied 

The  requirement  is  met  by  the  risk  management  practice. 

Partially  Satisfied 

The  requirement  is  partially  met  by  the  risk  management  practice.  Some  aspects  of  the 
requirement  are  not  met  satisfactorily. 

Unsatisfied 

The  requirement  is  not  met  by  the  risk  management  practice. 

Don’t  Know 

More  information  is  needed  to  evaluate  the  requirement. 

2.  After  you  evaluate  each  requirement,  document  the  rationale  for  your  response  in 
the  space  provided.  Note  where  your  response  is  based  on  objective  data  and  where 
it  is  based  on  more  subjective  data,  such  as  opinions. 
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Evaluation:  Framework  Requirements 


Requirement 

Response 

Stakeholder  Sponsorship 

1. 

Support  of  risk  management  by  key  stakeholders  is  tangible, 
active,  and  visible. 

□ 

Satisfied 

□ 

Partially  Satisfied 

Examples  of  sponsorship 

Organizational  policies;  memos  from  senior  management;  resources; 

□ 

Unsatisfied 

funding;  risks  discussed  at  management  meetings 

□ 

Don’t  Know 

Risk 

Management  Plan 

2. 

A  risk  management  plan  is  defined,  documented,  and  approved. 

□ 

Satisfied 

Examples  of  plan  content 

Objectives;  scope;  resources;  descriptions  of  methods  and  tools; 

□ 

Partially  Satisfied 

sources  of  risk;  risk  management  criteria;  communication  framework; 
schedule  and  triggers  for  conducting  evaluations;  effectiveness 

□ 

Unsatisfied 

measures 

□ 

Don’t  Know 

Risk  Sources 

3. 

Risk  sources  are  defined,  documented,  and  kept  current. 

□ 

Satisfied 

Examples  of  documents  containing  risk  sources 

Publicly  available  lists  and  taxonomies;  domain-specific  lists  and 

□ 

Unsatisfied 

taxonomies;  organizational  lists  and  taxonomies 

Examples  of  risk  categories 

□ 

Partially  Satisfied 

Program  management,  technical,  organizational,  infrastructure,  support 
services,  and  product 

□ 

Don’t  Know 

Risk 

Management  Criteria 

4. 

Risk  management  criteria  are  defined  and  documented. 

□ 

Satisfied 

Examples  of  risk  management  criteria 

Probability,  impact,  and  risk  exposure  criteria;  decision-making  criteria 

□ 

Unsatisfied 

(e.g.,  for  escalation  or  prioritization);  criteria  that  establish  risk  tolerance; 
criteria  for  communicating  with  collaborators,  partners,  subcontractors, 

□ 

Partially  Satisfied 

suppliers,  customers,  and  other  stakeholders 

□ 

Don’t  Know 
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Evaluation:  Framework  Requirements 


Rationale 

Stakeholder  Sponsorship 
1. 


Risk  Management  Plan 

2. 


Risk  Sources 

3. 


Risk  Management  Criteria 

4. 


47  |  CMU/SEI-2010-TR-017 


Evaluation:  Framework  Requirements  (continued) 


Requirement 

Response 

Tailored  Methods  and  Tools 

5.  Methods  and  tools  used  to  support  risk  management  activities 

□ 

Satisfied 

have  been  appropriately  tailored  for  use. 

□ 

Partially  Satisfied 

Examples  of  methods  and  tools 

Procedures  for  conducting  risk  management  activities;  risk  management 
criteria;  risk  sources;  worksheets;  automated  support  tools;  report 

□ 

Unsatisfied 

generators;  databases 

□ 

Don’t  Know 

Trained  Personnel 

6.  People  who  perform  risk  management  activities  are  prepared  to 

□ 

Satisfied 

conduct  them. 

□ 

Partially  Satisfied 

Examples  of  people  who  need  training 

Managers,  technical  leads,  and  staff  who  participate  in  risk  management 
activities;  risk  manager;  risk  database  administrator 

□ 

Unsatisfied 

Examples  of  types  of  training 

Awareness  training;  method  training;  tool  training 

□ 

Don’t  Know 

Risk  Statement 

7.  A  risk  statement  is  documented  for  each  risk  using  a  standard 

□ 

Satisfied 

format. 

□ 

Unsatisfied 

Examples  of  Items  that  influence  the  format  and  use  of  risk  statements 
Organizational  guidance  for  communicating,  documenting,  and  updating 

□ 

Partially  Satisfied 

risks;  requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders 

□ 

Don’t  Know 

Context 

8.  Context  is  documented  for  each  risk. 

□ 

Satisfied 

Examples  of  items  that  influence  the  format  and  use  of  context 
Organizational  guidance  for  communicating,  documenting,  and  updating 

□ 

Unsatisfied 

risks;  requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 

□ 

Partially  Satisfied 

stakeholders 

□ 

Don’t  Know 

Examples  of  context 

Root  causes;  aggravating  conditions;  mitigating  conditions;  relationships 
and  dependencies  with  other  risks 
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Evaluation:  Framework  Requirements  (continued) 


Rationale 

Tailored  Methods  and  Tools 

5. 


Trained  Personnel 

6. 


Risk  Statement 

7. 


Context 

8. 
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Evaluation:  Framework  Requirements  (continued) 


Requirement 

Response 

Probability 

9.  Probability  is  evaluated  and  documented  for  each  risk. 

□ 

Satisfied 

Examples  of  items  that  influence  the  use  of  probability 

□ 

Partially  Satisfied 

Probability  criteria;  organizational  guidance  for  assessing  probability; 
requirements  of  methods  and  tools;  needs  of  decision  makers, 

□ 

Unsatisfied 

collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders 

□ 

Don’t  Know 

Impact 

1 0.  Impact  is  evaluated  and  documented  for  each  risk. 

□ 

Satisfied 

Examples  of  items  that  influence  the  use  of  impact 

□ 

Partially  Satisfied 

Impact  criteria;  organizational  guidance  for  assessing  impact; 
requirements  of  methods  and  tools;  needs  of  decision  makers, 

□ 

Unsatisfied 

collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders 

□ 

Don’t  Know 

Risk  Exposure 

1 1 .  Risk  exposure  is  evaluated  and  documented  for  each  risk. 

□ 

Satisfied 

Examples  of  items  that  influence  the  use  of  risk  exposure 

□ 

Unsatisfied 

Risk  exposure  criteria;  organizational  guidance  for  assessing  risk 
exposure;  requirements  of  methods  and  tools;  needs  of  decision 

□ 

Partially  Satisfied 

makers,  collaborators,  partners,  subcontractors,  suppliers,  customers, 
and  other  stakeholders 

□ 

Don’t  Know 

Risk  Profile 

1 2.  A  profile  of  all  risks  is  developed,  documented,  and  kept  current. 

□ 

Satisfied 

Examples  of  items  that  influence  the  development  of  a  risk  profile 

□ 

Unsatisfied 

Organizational  guidance  for  communicating,  documenting,  and  updating 
the  risk  profile;  requirements  of  methods  and  tools;  format  of  risk 

□ 

Partially  Satisfied 

statements;  risk  profile  format;  needs  of  decision  makers,  collaborators, 
partners,  subcontractors,  suppliers,  customers,  and  other  stakeholders 

□ 

Don’t  Know 
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Evaluation:  Framework  Requirements  (continued) 
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Evaluation:  Framework  Requirements  (continued) 


Requirement 


Response 


Mitigation  Approach 

1 3.  A  mitigation  approach  is  established  and  documented  for  each 
risk. 

Examples  of  items  that  influence  selection  of  a  mitigation  approach 
Organizational  guidance  for  communicating,  documenting,  and  updating 
a  mitigation  approach;  requirements  of  methods  and  tools;  needs  of 
decision  makers,  collaborators,  partners,  subcontractors,  suppliers, 
customers,  and  other  stakeholders;  risk  tolerance;  decision-making 
criteria 

Examples  of  common  mitigation  approaches 
Accept  a  risk  and  take  no  action;  transfer  a  risk  to  another  party; 
restructure  activities  to  avoid  a  risk  by  eliminating  the  possibility  of  it 
occurring;  take  action  to  reduce  or  contain  a  risk 


□  Satisfied 

□  Partially  Satisfied 

□  Unsatisfied 

□  Don’t  Know 


Mitigation  Plan 

14.  A  mitigation  plan  is  defined  and  documented  for  each  risk  that  is 
actively  being  addressed. 

Examples  of  items  that  influence  development  of  a  mitigation  plan 
Organizational  guidance  for  communicating,  documenting,  and  updating 
a  mitigation  plan;  requirements  of  methods  and  tools;  needs  of  decision 
makers,  collaborators,  partners,  subcontractors,  suppliers,  customers, 
and  other  stakeholders;  risk  tolerance 

Examples  of  a  mitigation  plan’s  content 

Objectives  for  the  plan;  resources  responsible  for  completing  each 
action;  schedule  for  completing  all  actions;  funding  allocated  to 
performing  the  plan’s  actions;  measures  for  tracking  the  execution  of  the 
plan  (in  relation  to  the  schedule  and  cost);  measures  for  tracking  the 
effectiveness  of  the  plan;  a  contingency  plan  and  triggers  when 
appropriate 


□  Satisfied 

□  Partially  Satisfied 

□  Unsatisfied 

□  Don’t  Know 


Executed  Mitigation  Plan 

15.  Mitigation  plans  are  implemented  as  intended  (unless 
circumstances  force  a  change  in  direction). 

Examples  of  items  that  influence  plan  execution 
Resources  available  for  plan  execution;  funding  allocated  to  the  plan; 
responsibility  for  implementing  the  plan;  authority  for  implementing  plan; 
verification  of  completion;  visible  support  of  management 

Examples  of  data  that  can  be  used  to  evaluate  plan  implementation 
Tracking  measures  for  effectiveness  and  efficiency  of  mitigation  plan 
execution;  tracking  measures  for  verifying  plan  completion;  triggers  for 
contingency  or  alternate  plans 


□  Satisfied 

□  Unsatisfied 

□  Partially  Satisfied 

□  Don’t  Know 
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Evaluation:  Framework  Requirements  (continued) 


Rationale 

Mitigation  Approach 

13. 


Mitigation  Plan 

14. 


Executed  Mitigation  Plan 

15. 
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Evaluation:  Framework  Requirements  (continued) 


Requirement 

Response 

Tracking  Data 

16. 

Data  for  tracking  mitigation  plans  are  collected,  analyzed, 

□ 

Satisfied 

documented,  and  reported. 

□ 

Partially  Satisfied 

Examples  of  items  that  influence  collection  of  tracking  data 

Organizational  guidance  for  selecting  tracking  measures;  organizational 
guidance  for  communicating,  documenting,  and  updating  tracking  data; 

□ 

Unsatisfied 

requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders;  approach  for  collecting  measurement  data;  approach  for 
analyzing  measurement  data;  frequency  requirements  for  collecting 
tracking  data 

□ 

Don’t  Know 

Examples  of  tracking  measures 

Tracking  measures  for  effectiveness  and  efficiency  of  mitigation  plan 
execution;  tracking  measures  for  verifying  plan  completion;  triggers  for 
contingency  or  alternate  plans 

Tracking  Decision 

17. 

Tracking  decisions  for  mitigation  plans  are  documented 

□ 

Satisfied 

appropriately. 

□ 

Partially  Satisfied 

Examples  of  items  that  influence  tracking  decisions 

Organizational  guidance  for  communicating,  documenting,  and  updating 
tracking  decisions;  requirements  for  approving  tracking  decisions; 

□ 

Unsatisfied 

requirements  of  methods  and  tools;  needs  of  decision  makers, 
collaborators,  partners,  subcontractors,  suppliers,  customers,  and  other 
stakeholders;  decision-making  criteria 

□ 

Don’t  Know 

Examples  of  common  tracking  decisions 

Modify  the  mitigation  approach  and  develop  a  new  plan;  modify  an 
existing  mitigation  plan;  implement  a  contingency  plan;  close  a  risk 

Controlled  Risk  Management  Assets  and  Work  Products 

18. 

Selected  risk  management  assets  and  work  products  are  under 
configuration  control. 

□ 

Satisfied 

□ 

Unsatisfied 

Examples  of  assets  under  configuration  control 

Risk  management  plan;  methods  and  tools;  risk  sources;  risk  criteria 

□ 

Partially  Satisfied 

Examples  of  work  products  under  configuration  control 

Don’t  Know 

Risk  profile;  mitigation  plans;  tracking  decisions;  status  reports 

LI 
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Rationale 

Tracking  Data 

16. 


Tracking  Decision 

17. 


Controlled  Risk  Management  Assets  and  Work  Products 

18. 
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Evaluation:  Framework  Requirements  (continued) 


Requirement 

Response 

Lessons  Learned 

19. 

Lessons  learned  are  collected  and  documented  for  the  risk 

□ 

Satisfied 

management  practice. 

□ 

Partially  Satisfied 

Examples  of  items  that  influence  lessons  learned 

Requirements  for  developing  lessons  learned;  needs  of  decision 
makers,  collaborators,  partners,  subcontractors,  suppliers,  customers, 

□ 

Unsatisfied 

and  other  stakeholders;  types  of  effectiveness  measures  collected  for 
the  risk  management  practice;  strengths  of  the  risk  management 
practice;  weaknesses  of  the  risk  management  practice;  changes  in  best 
practices;  new  standards  or  changes  to  existing  standards  or 
regulations;  new  methods  and  tools  or  changes  to  existing  methods  and 
tools 

□ 

Don’t  Know 

Updates  to  Risk  Management  Practice 

20. 

The  risk  management  practice  is  updated  as  appropriate  based 

□ 

Satisfied 

on  lessons  learned. 

□ 

Unsatisfied 

Examples  of  items  that  influence  how  lessons  are  incorporated 

Change  management  process;  organizational  guidance  for  managing 

□ 

Partially  Satisfied 

change;  needs  of  decision  makers,  collaborators,  partners, 
subcontractors,  suppliers,  customers,  and  other  stakeholders 

□ 

Don’t  Know 

Examples  of  items  that  could  be  updated  or  changed 

Risk  management  plan;  funding  for  risk  management;  methods;  tools; 
resources;  training 
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